How To Use Multi-region Deployment And Failover Strategy For Huawei Cloud Server In Japan

1.

overview: why huawei cloud is used for multi-region deployment in japan

- for users in japan and surrounding areas, choosing huawei cloud tokyo (ap-northeast-1) and singapore (ap-southeast-1) dual-active or active-standby can reduce latency and improve availability.
- multiple regions can cope with service interruptions caused by computer room power outages, network failures, single-point hardware failures and ddos attacks.
- combined with cdn, load balancing and dns, uniform traffic or disaster recovery traffic can be distributed to available areas.
- cost and complexity are controllable, and smooth switching is achieved through on-demand expansion and automated scripts.
- target indicator recommendations: rto ≤5 minutes (switchover) and rpo ≤5 minutes (acceptable range of data loss).

2.

infrastructure and instance configuration recommendations

- it is recommended to deploy front-end and computing nodes in the main tokyo area. example instance: ecs 2 vcpu / 8 gb ram / 100 gb ssd (for web applications).
- reserve at least ecs with the same specifications as hot standby or cold standby in the standby area (singapore or osaka).
- network bandwidth configuration example: the public network bandwidth is 25 mbps (burst) for ordinary sites, and the peak demand can be configured to 100 mbps or higher.
- the database uses rds master-slave or cross-region backup. example: mysql rds master database is in tokyo, and the standby database is asynchronously replicated to singapore. the latency target is <1000 ms.
- storage and backup: object storage (obs) cross-region replication, block storage (evs) daily snapshots and off-site backup.

3.

traffic scheduling and failover mechanism

- dns low ttl policy (60 seconds) combined with health check to achieve fast dns switching; use huawei cloud dns or third-party dns service.
- load balancing (elb/clb) performs intra-regional load distribution, and cooperates with cross-regional health detectors to automatically offline unhealthy instances.
- global traffic management (gtm) or anycast+cdn reduces switching risks. gtm can switch traffic by geography or delay routing.
- automated scripts and runbooks: after a fault is triggered, the script is triggered to automatically switch the dns/writeback configuration and expand the backup zone.
- ddos protection: enable huawei cloud waf and anti-ddos, blackhole thresholds and cleaning strategies to automatically take over traffic in the event of a failure.

4.

database and file synchronization strategy (including rpo/rto examples)

- scheme a (dual-active): primary write/secondary write is read in two areas at the same time, suitable for no shared files or using application layer conflict resolution, rto ~30s, rpo ~0.
- scheme b (primary and backup asynchronous): asynchronous replication of the primary database in tokyo and the secondary database in singapore, suitable for most scenarios, rto 1-5 minutes, rpo 0-300 seconds.
- object storage cross-region replication example: daily incremental synchronization + real-time log replication, recovery point example: data can be traced within 30 minutes.
- the file system can be synchronized with rsync/oss or use distributed file services (compatible with nfs) to achieve near-real-time synchronization. bandwidth requirements are calculated based on the write rate.
- transaction volume example: the primary database has a transaction tps of 200 per second, and a peak write rate of 10 mb/s. it is recommended that the backup database network bandwidth be at least 50 mbps with concurrent replication capabilities.

5.

real case: japanese e-commerce company deploys huawei cloud in multiple regions

- background: a medium-sized japanese e-commerce company, the main station in tokyo has a daily pv of 1.2m and a peak concurrency of 15k.
- architecture: tokyo: 3 ecs (4 vcpu/16gb) + elb + rds master (mysql 4 vcpu/16gb) + obs; singapore: 2 ecs hot backup + rds read-only backup.
- monitoring data: the average delay in tokyo is 25 ms, and the peak tokyo->singapore database replication delay is 450 ms.
- fault drill: simulated switching during a power outage in the main area computer room, dns low ttl + automated script switched 80% of the traffic to singapore within 120 seconds, rto actual measurement was 2 minutes and 10 seconds.
- cost and effect: the additional cost of multi-region is about 30% of the main site operation and maintenance cost, but the availability is increased from 99.5% to 99.98%.

6.

practical suggestions, monitoring and drill checklists

- it is recommended to conduct full fault drills regularly (at least once a quarter). the drills include dns switching, database switching and rollback steps.
- monitoring items include: host cpu/memory, network bandwidth, database replication delay, elb health check and cdn cache hit rate.
- automation and ci/cd: use terraform/ansible to manage infrastructure and quickly activate instances of the same specifications in the backup zone.
- notes on sla and contracts: confirm the sla, peak bandwidth charges, and cross-region data transmission charges for the huawei cloud region.
- security: domain name resolution policy adds domain name anti-hijacking, enables waf rules and anti-ddos packages, and sets log auditing and alarms.

project	tokyo (main area)	singapore (preparatory region)
ecs configuration	2 vcpu / 8 gb ram / 100 gb ssd	2 vcpu / 8 gb ram / 100 gb ssd
bandwidth (public network)	25 mbps (base), 100 mbps peak	25 mbps (base), 100 mbps peak
database	rds mysql master (4 vcpu/16gb)	rds read-only backup (asynchronous replication)
rto/rpo (target)	rto ≤5 minutes/rpo ≤5 minutes	rto ≤5 minutes/rpo ≤5 minutes

7.

conclusion and next implementation route

- first step: build an environment in tokyo and create a mirror in singapore to ensure network interoperability and vpc peering or vpn connection.
- step 2: deploy monitoring alarms, low-ttl dns and automated switching scripts to practice database failover.
- step 3: launch cdn and anti-ddos strategies, optimize caching rules and reduce pressure on the origin site.
- step 4: regularly review rpo/rto goals and adjust resources and bandwidth according to traffic and business growth.
- optional: consider introducing gtm or anycast to obtain more fine-grained traffic control and shorter switching time.